The design of a typical computer or information handling system requires the establishment of a fixed number of addressable registers, such as general purpose registers (GPRs), condition registers (CRs), and floating point registers (FPRs) for the programmer to use in designing programs for the information handling system.
The design of computers and computer programs is based on the assumption that computer or information handling system program instructions are executed by the information handling system in the order in which they are written in the program and loaded into the information handling system. While instructions must logically appear to the information handling system to have been executed in program order, it has been learned in an effort to improve computer performance that some instructions do not have to be physically performed in program order, provided that certain dependencies do not exist with other instructions. Further, if some instructions are executed out of order, and one of such instructions is a branch instruction, wherein a branch prediction is made to select the subsequent instruction sequence, a need to restore the registers affected by instructions in the predicted branch to their original values can occur if the branch is mispredicted. In such a case, the information handling system is restored to the condition before the branch was taken. The process of efficiently executing instructions out of order requires that values for registers prior to the predicted branch be maintained for registers affected by the instructions following the branch, while provision is made to contingently store new values for registers affected by instructions following the predicted branch. When branch instructions are resolved, the contingency of the new register values is removed, and the new values become the established values for the registers. The above-described register management technique is referred to as register renaming. For an example of a register management system utilizing register renaming techniques, see U.S. Pat. No. 5,134,561, of common assignee herewith.
Register renaming may also be needed upon the occurrence of an interrupt condition such as for overflow conditions or page faults and the like.
There are two basic approaches to register renaming. The first approach is referred to as the future file approach. In this approach, all updates to a value stored in an architected register are stored or assigned to future file entries in a rename queue or register until the data is available and the instruction that is causing this update is committed or becomes non-speculative. When the instruction is committed, the update in the oldest future file entry assigned to the architected register is written to the architected register.
Thus, the rename queues or registers contain the speculative update values for the architected registers, and the architected registers contain the non-speculative values for the architected registers. An instruction which reads the value of an architected register first determines if any future file entries have been assigned to that architected register in the rename registers. If no future file entries have been assigned, the instruction reads the value in the architected register. If one or more future file entries have been assigned, the instruction reads the value from one of the rename registers.
The second register renaming approach is referred to as the history file approach. With this approach, the architected registers contain the speculative update values for the architected register, and the rename registers contain the values of the architected registers prior to being speculatively updated. Thus, an instruction which reads the value of an architected register simply reads the speculative value in the architected register.
Upon the occurrence of an interrupt or a mispredicted branch instruction, non-speculative values for the architected registers must be determined. With the future file approach, the non-speculative values for the architected registers would be stored in the architected registers themselves, whereas with the history file approach, the non-speculative values for the architected registers would be stored in the rename registers.
Thus, upon the occurrence of an interrupt or a mispredicted branch instruction, the age order of a value stored in the rename register is critical to determining the non-speculative values of the architected registers in the history file approach. Prior art rename registers used in the history file approach utilized shift registers which shift each history file entry down as an entry is removed from the rename registers as a result of being retired or written to an architected register to restore the architected register with a non-speculative value existing prior to the interrupt or mispredicted branch instruction. By using a shift-down register array for the rename registers, the history file entries remain in age order. The problem with this age order shift register approach is the excessive power required for the shifting.
What is needed is a register renaming approach which eliminates the need for shift rename registers to save power while minimizing the complexity required to track the age order of values stored in the rename registers.